1. Field of the Invention
The present invention relates to bridged serial bus. More particularly, the present invention relates to net update oscillation problems in serial bus bridges such as the IEEE 1394.
2. Description of the Related Art
A net refers to a collection of buses which are interconnected by bridges. According to the IEEE definition, a bridge implements two portals and forwards asynchronous subactions, and may also forward isochronous subactions according to route information which is stored. Each bus that forms a net has an individual identifier that is unique if the net is stable and configured properly. In particular, in an IEEE 1394 net, there can be up to 1,023 logical buses and up to 63 nodes on each bus. Loop interconnection is physically allowed between buses within a net. However, loop(s), if any, shall be eliminated by muting at least one bridge per a loop according to IEEE1394 bridge draft standard. When two or more bridged nets are connected, a net update procedure is required.
According to IEEE1394.1 bridge draft standard version 1.00, prime portal is defined as a singular portal within a net of interconnected buses and clan is defined as a group of affiliated bridge portals that exhibit allegiance to the same prime portal. When two nets are connected, it is possible for bridge portals on the same bus to belong to different clans. However, this is a temporary condition that is resolved by net update procedures.
When a coordinator finds portals belong to different clans, the coordinator shall select one prime portal and update packet routing information according to IEEE1394.1 bridge draft standard. The coordinator, then, shall send an UPDATE_ROUTE message to each portal on its local bus in order to update each portal's packet routing information and clan affinity.
If a new update process is initiated while another net update(s) is(are) being processed, these net update processes shall be merged into one. Otherwise, a net can not be configured properly. According to the IEEE1394.1 draft standard version 1.00, only a coordinator can detect net update collision and initiate new update processes after selecting a surviving prime portal and updating packet routing information.
However, a problem arises in that if a bridge observes a net update process on one portal while processing another net update received on the other portal, two different UPDATE_ROUTE messages related to the two different net updates can be passed to each other at the bridge without being merged into one. Then, both bridge portals are updated with the UPDATE_ROUTE messages exchanged with each other, and then initiate bus resets on their local buses.
As a result, each coordinator on each bus observes a new different net update collision. Two coordinators then may send different UPDATE_ROUTE messages to each portal on its local bus because of the different net update collisions. If these happen, the same bridge will observe a net update process at one portal while processing another net update received at the other portal again. It could result in an infinite net update oscillation problem.
For example, FIG. 1 illustrates a time flow diagram 100 of an example that two UPDATE ROUTE messages are received by a bridge on its two local buses and the two UPDATE ROUTE messages will be passed by and be forwarded to the other buses.
A net update process starts when a bridge receives a net update message from a portal. Normally, after a coordinator (i.e. the bridge portal in charge of net updates) receives a net update message, the bridge's clan information is updated, and the process ends with the initiation of a bus reset on the other portal's bus.
The coordinator (not shown) on the first bus A (not shown) sends a net update message 120, which at point 140 is received by bus B. At approximately the same time 130, the coordinator (not shown) on bus B sends a net update message to bus A, which is received at time 110. Thus there is a “crossing” of update messages between the start from one bus to the reset on the other bus, in the time frame referred to as a net update period (the period from 130 to 140).
When first bus A receives the clan information, which includes reset information from second bus B, it updates its clan information and a reset is initiated.
Thus, the respective coordinators for A and B will still detect “competition” regarding the bridge clan information and both will again perform net updates.
Subsequently, the two coordinators will initiate different update processes again. The bridge may then again receive two different net update messages on both portals by the crossing at 150. An infinite net update loop can be the result. In other words, the bridge continuously receives two net update messages on both portals and forwards them to the buses infinitely. In such a situation, the net configuration is never finished. This looping is referred to as net update oscillation.